ComfyUI で使える高速化・VRAM 技術
ComfyUI は PyTorch attention = FlashAttention がデフォルトで使われる。昔は xformers（中身は FlashAttention）も使われていたが、最近では PyTorch attention を使うことが多い。
ComfyUI のオプションは comfy/cli_args.py を見るのが早い。
目次
ComfyUI のメモリ管理
モデルを VRAM に移動しても RAM 上のモデルは解放されないことに注意。
ComfyUI のデフォルト挙動
- ワークフロー上にあっても、ノードが実行されない限り RAM にモデルがロードされることはない
- テキストエンコーダーがロードされるのは CLIPTextEncode 実行時であって、Load CLIP ノード実行時ではない
- モデルがロードされるのは KSampler 実行時であって、Load Checkpoint 等のノードではない
- ノード実行時モデルを VRAM にロードし実行する
- 実行後モデルを VRAM から削除（highvram オプションはこれを無効にする）
- ワークフロー実行中に、RAM にロードされたモデルをアンロードする方法はない（たぶん）
ComfyUI はワークフローで使うモデルをすべて RAM にロードし、実行中はアンロードできない。Wan 2.2 を fp16 で実行する場合、最低 68.4 GB の RAM が必要になる。Q4_K_M を使う場合は 31 GB の RAM が必要。
| モデル | サイズ(GB) |
|---|---|
| umt5_xxl_fp8 | 9.0 |
| wan2.2_vae | 1.4 |
| high-fp16 | 29.0 |
| low-fp16 | 29.0 |
モデルと VRAM
画像生成モデルの場合、モデルサイズ ≒ VRAM 使用量だが、動画生成モデルでは違う。
動画生成モデルは生成途中の動画データも数 GB の VRAM を使用するので、モデルサイズだけで VRAM が足りるかどうかを判定できない。
RTX 5090 は VRAM 32 GB で Wan 2.2 fp16 は 29 GB なので、モデルがすべて VRAM に乗ると考えがちだが、生成動画分の VRAM と OS 管理分とが必要なので足りない。
PCI Express の帯域がボトルネックになることはまずない
4.0 は２GB/レーン なので、x16 なら 32 GB/s。5.0 は４GB/レーンなので、x16 なら 64GB/s。
モデルの半分以上が VRAM に乗らない場合、推論１回あたりのデータ転送量はモデルサイズと同じになる。このような巨大なモデルで 1 it/s を超えることはないので、PCI Express の帯域がボトルネックになることはまずない。
20 GB のモデルで VRAM に 15 GB 乗っている場合、推論１回あたりのデータ転送量は 10 GB（不足分５GB + 次回推論時に VRAM から削除した分の再ロード５GB）になる。このケースで PCI Express 4.0 x16 の場合は、3 it/s までは PCI Express の帯域はボトルネックにならない。
これは演算ボトルネックの画像・動画生成の場合であって、メモリ速度ボトルネックの LLM では PCI Express の帯域がボトルネックになりうる。DDR5 デュアルチャンネルの帯域 > PCI Express 5.0 x16 の帯域なので。
SSD へのスワップの監視
Windows のタスクマネージャのメモリを見てもスワップはわからない。
２回目以降の生成中に SSD の使用率が大幅に上昇するならスワップが発生している可能性が高い。
ComfyUI のメモリ使用量
タスクマネージャのプロセスタブの python を見るのが早い。
タスクマネージャのメモリタブ
| 項目 | 意味 |
|---|---|
| 使用中の物理メモリ量 | |
| 利用可能 | 空き物理メモリ量 |
| コミット済み | メモリアドレスが予約済みのメモリ量。 予約されていても読み書きが発生していない状態では、物理メモリにもストレージにも領域確保は発生しない |
| キャッシュ済み | 最近使用したデータを再利用するための一時的なメモリ領域 |
| ページプール | Windows カーネルが使用するメモリで、ストレージ等に退避可能なメモリ領域。 気にする必要はない |
| 非ページプール | Windows カーネルが使用するメモリで、ストレージ等に退避不可能なメモリ領域。 気にする必要はない |
「コミット済み - 使用中 = スワップ量」のような間違いを信じている人が非常に多い。メモリはアドレスを予約した後、実際に読み書きされるまで、物理メモリやストレージの領域確保は発生しない。なのでコミット済みを見てもどれだけのスワップが発生しているかはわからない。
VirtualAlloc に MEM_RESET を指定すれば、メモリアドレスを維持したまま物理メモリを解放できる。なので、「コミット済み」を変化させずに「使用中（圧縮）」の量を減らすことも可能。
VRAM
GGUF
GGUF はモデル量子化技術。RAM から VRAM へ必要な量だけ転送して実行する。
Block Swap（ComfyUI 0.3.70 以降は非推奨）
VRAM のモデルのブロックを交換しつつモデルを実行できる。ComfyUI 自体のこの機能が実装されているので、ComfyUI 0.3.70 以降は Block Swap ノードは非推奨となっている。
ComfyUI-MultiGPU DisTorch 2.0
複数 GPU の VRAM と RAM とに好きなようにブロックを割り付けできる
raylight
複数 GPU に分割してモデルを配置でき、それぞれの GPU で独立して画像を同時に生成できる。SD 1.5 と SDXL には非対応。
１枚だけ生成する速度は高速化しないが、複数枚生成する場合のスループットは向上する。たとえば、RTX5090（45万円）で２枚生成する速度と RTX5070Ti（13万円*2 = 26万円）２台で同時に２枚生成する速度とが大体同じ。
pinned-memory
RAM に確保したモデルがページングされなくなる。ページングとは RAM も VRAM も不足した場合、OS が SSD や HDD を使って処理を継続する機能。pinned-memory はこれを無効化する。
つまり pinned-memory が有効な状態で RAM も VRAM も不足すると OOM が発生する。
pinned-memory を無効にするには --disable-pinned-memory オプションをつけて ComfyUI を起動する。
python main.py --disable-pinned-memory
reserve-vram
OS が利用する VRAM 量を指定する。Kijai は --reserve-vram 2 を指定することを推奨している。
最新の ComfyUI は自動で VRAM と RAM とにモデルを割り振る。しかし、OS が VRAM を使用して VRAM が不足すると共有 VRAM が使用され、生成速度が劇的に低下する。reserve-vram はこれを回避できる。
当然 ComfyUI が使用できる VRAM 量が減少するため生成速度は低下する可能性が高い。
python main.py --reserve-vram 2
highvram
ComfyUI の実行フロー
- RAM にモデルをロード
- ノード実行時 VRAM にロード
- 実行
- モデルを VRAM から削除
highvram を指定するとモデルを VRAM から削除しなくなる。
python main.py --highvram
モデルウェイト最適化
量子化
量子化はモデルの表現ビット数を減らしてモデルサイズを減らす。VRAM 速度がボトルネックの場合は推論速度も上がる。メモリ速度がボトルネックになっている LLM では量子化で推論速度も上がるが、演算ボトルネックの画像・動画生成 AI では推論速度は上がらない。
| 手法 | 説明 |
|---|---|
| GGUF | 拡張子が GGUF のモデル。VRAM にモデルが乗らなくても RAM から VRAM にブロックを転送して実行可能 |
| fp8 | RTX 4000 番台以降ではハードウェアで高速に実行できる |
| DFloat11 | 11bit で圧縮して演算時に bf16 に展開する。高速化はしないがロスレス圧縮なので、劣化なしで bf16 を 30% 圧縮できる |
| SVDQuant | モデルを外れ値とそうでない部分とに分けて量子化する手法。nuncyaku という名前で呼ばれている |
| TensorRT | 量子化＋生成解像度指定等の最適化で効率的に実行できるようにモデルを変換して高速化する |
| SageAttention | FlashAttention-2 を INT8 や INT4 で量子化する |
8 bit 量子化比較
fp8 はRTX 4000 番台以降での評価。scaled_fp8 は高品質かつ高速なのでベストな選択。
- 品質：Q8_0 > scaled_fp8 >> fp8
- 速度：scaled_fp8 = fp8 >> Q8_0
| 手法 | 品質 | 推論速度 |
|---|---|---|
| Q8_0 | fp16 に匹敵 | 遅い |
| scaled_fp8 | Q8_0 に匹敵 | 速い |
| fp8 | Q5_K_M や Q6_K_M 相当 | 速い |
蒸留
モデルファイル名に 4step や 8step が入っていると蒸留モデルの可能性が高い。最近は LoRA 形式で配布されることが多い。
コード最適化
FlashAttention
pytorch 2.2 で FlashAttention-2 に対応し、約２倍高速化した。
pytorch 2.5 で cuDNN バックエンドの統合により scaled dot product attention（SDPA）が FlashAttention-2 比で 75% 高速化した。H100 以降の業務用 GPU では cuDNN バックエンドの SDPA がデフォルトで使われる。
FlashAttention-3 は H100 以降の業務用 GPU で使用でき、FlashAttention-2 より 50%～100% 高速。
torch.compile
モデルをネイティブコードに変換して高速化する。SageAttention と同時に使われることが多い。
ComfyUI 公式の TorchCompileModel ノードでできる。初回実行時、モデルのコンパイルに数分かかる。モデルによっては機能しない。
triton
モデルのコードをカスタム GPU カーネルに変換するライブラリ。SageAttention と同時に使われることが多い。
Windows 用バイナリも増えてきて簡単にインストールできるようになった。
pip install -U 'triton-windows<3.3'
SageAttention
アテンションの計算に SageAttention を使うことで高速化する。SDXL は U-Net を使用しており、アテンションはプロンプトの取り込み部分にしか使われていないので、SDXL は SageAttention を使ってもほとんど高速化しない。
SDXL 以降の画像生成・動画生成 AI は拡散トランスフォーマーなので SageAttention で高速化できる。
- Step-by-Step Full ComfyUI with Sage Attention install instructions for Windows 11 and 4k and 5k Nvidia cards
- Comfy-WaveSpeed
- ComfyUI-KJNodes
TeaCache
「モデルに入力するノイズ画像 - デノイズ後の画像」の差分ベクトルはステップ中盤以降はほとんど変化しないことが多い。なのでこの差分ベクトルをキャッシュして使いまわしてデノイズすることで、推論を丸ごとスキップして高速化する。